drivers: stepper: introduce rudimentary trapezoidal ramp control by jilaypandya · Pull Request #88564 · zephyrproject-rtos/zephyr

jilaypandya · 2025-04-13T19:25:49Z

Trapezoidal Ramp Control for Stepper Motors:

The idea is to create a ramp lib that can be integrated in any driver, the step counting for the driver itself stays unaffected by integration a ramp lib

I have been using Shell to see how the ramping looks like.

Starting This PR to get some early feedback.

Integration in driver

References:
https://www.boost.org/doc/libs/1_81_0/libs/safe_numerics/example/stepper-motor.pdf
Equation 13 in the above mentioned paper can also be seen in this app note.
https://ww1.microchip.com/downloads/en/Appnotes/doc8017.pdf (Thanks @andre-stefanov :) )

Known open points:

Integrate ramp control for stepper_run as well
use of sqrt in calculate_start_velocity, this function gets called once when the ramping starts from zero-velocity
copied isqrt
Implement unit tests
Introduce DT based selection of trapezoidal ramp, allowing inclusion of other ramps in future

Update: 23.04.2025
Thanks @andre-stefanov for contributing unit-tests :)

andre-stefanov · 2025-04-13T21:40:49Z

is max_velocity really needed? next step interval depends only on current interval and acceleration/deceleration values.

the actual limit will be given by the requested stepper interval

Trying to depict a trapezoidal ramp. I am also using max_velocity to check for valid_timing in move_by and move_to. But i'll check this again for sure if it is actually needed :).

In my experience, the speed set via set_microstep_interval is sufficient.

Okay we can use that function, but we definitely need to have a better name for it though. set_microstep_interval atleast imo sounds like this interval will take place with immediate effect. Probably something like set_target_step_interval ?

Using the current micro-step interval implementation also requires changes to pre-decel-steps, as it is dependent on the speed. My recommendation would be to use the current micro-step interval in combination with the deceleration value for this

jbehrensnx · 2025-04-14T06:32:30Z

In my experience, the speed set via set_microstep_interval is sufficient.

jbehrensnx · 2025-04-14T07:07:13Z

You don't need max_velocity, you already have set_microstep_interval.

We need to find a consensus on how to rename that function, set_microstep_interval imo signifies more like a tick time, could be compared with for instance , can_set_bitrate.

I would say, once this PR is merged, the CONFIG_STEPPER_RAMP can be deleted and all motors should support ramping by default.

jbehrensnx · 2025-04-14T07:13:37Z

I would prefer a dt-binding instead to allow for a per stepper-controller decision on using ramps or not.

done. However, you would need one such variable for the source to be included, or is there a better way?

I think there is a Kconfig extension for checking if a property is present on a compatible:

drivers/dma/Kconfig.mcux_edma:12: depends on $(dt_compat_any_has_prop,$(EDMA_COMPAT),$(REV_PROP),2)

but nothing like dt_any_of_driver_class_has_prop, which would be neat.

jbehrensnx · 2025-04-14T07:20:55Z

You cant always use the approximation. You will need to use the accurate algorithm using the sqrt for a number of steps after starting accelerating and a couple of steps before stopping when decelerating. This is because of the approximation error.

jbehrensnx · 2025-04-14T07:24:48Z

My PR 88342 already uses the same algorithm (through I forgot to mention the algorithm admittedly) for a step-dir implementation. Several decisions made during development for that are relevant for this PR as well, so it should be included in the discussion.

dipakgmx · 2025-04-14T21:20:39Z

This is not related to the changes made in this PR, but could the functions move_to & move_by call either of them, I mean, in move_by, call move_to(current_pos+move_by_target)? It seems to me that some bits of code are repeated in both the functions (or thats what I felt when reviewing)

faxe1008 · 2025-04-22T15:00:50Z

+/**
+ * @brief Stepper ramp profile
+ */
+struct stepper_ramp_profile {


Why not have this in stepper.h directly?

coz then ramp.h would need to include stepper.h and i wanted to keep the ramp.h as decoupled from the stepper.h as possible.

Need some feedback on this actually, how about instead of stepper_set_ramp_profile(ramp_profile), we do something like stepper_set_timing_data(accel, max_velocity, decel) and then we put ramp_profile in ramp.h

done moved to stepper.h

faxe1008 · 2025-04-22T15:06:14Z

I think there is a Kconfig extension for checking if a property is present on a compatible:

drivers/dma/Kconfig.mcux_edma:12: depends on $(dt_compat_any_has_prop,$(EDMA_COMPAT),$(REV_PROP),2)

but nothing like dt_any_of_driver_class_has_prop, which would be neat.

faxe1008 · 2025-04-22T15:10:51Z

+ */
+typedef void (*stepper_ramp_reset_ramp_runtime_data_t)(const struct stepper_ramp_config *config,
+						       struct stepper_ramp_common *ramp_common,
+						       const bool is_stepper_dir_changed,


would it maybe make the API more stable when you move is_stepper_dir_changed etc. into the runtime data?

yep that's correct :), Will do it in the next push.

faxe1008 · 2025-04-25T13:09:58Z

Directly return this?

faxe1008 · 2025-04-25T13:10:39Z

Return this directly

jbehrensnx · 2025-04-28T07:47:39Z

The non ramp part uses a if DIRECTION_POSITIVE else if DIRECTION_NEGATIVE ordering and I would keep it consistent.

thanks. done

jbehrensnx · 2025-04-28T08:07:27Z

Suggested change

(2 * current_step_interval) / (4 * ramp_position + 1);

(2 * current_step_interval) / (4 * ramp_position + 3);

Using this, you effectively add 0.5 to ramp position, calculating the new interval based on the middle of the ramp segment and not the start, improving acceleration behavior. Note that your deceleration calculation already does this.

jbehrensnx · 2025-04-28T08:45:26Z

This is an interval and not a velocity.

jbehrensnx · 2025-04-28T08:52:05Z

Using the current micro-step interval implementation also requires changes to pre-decel-steps, as it is dependent on the speed. My recommendation would be to use the current micro-step interval in combination with the deceleration value for this

Introduce rudimentary trapezoidal ramp control using following paper: https://www.boost.org/doc/libs/1_81_0/libs/safe_numerics/example/stepper-motor.pdf Signed-off-by: Jilay Pandya <jilay.pandya@outlook.com>

testing following criteria: - distance profile - first acceleration interval - next step intervals Signed-off-by: Andre Stefanov <mail@andrestefanov.de>

jbehrensnx · 2025-04-28T09:19:14Z

As a general thing, in my experience, you need picosecond resolution for the ramp calculations, which are then converted to nanoseconds for the stepper controllers (but saving the picosecond values for the next step). Not sure if your 0.676 to counteract approximation inaccuracies reduces accuracy so much that this no longer matters.

Could could you maybe test if in an acceleration towards 50 or 200 steps/s in 1 sec actually takes 1 second? I remember during my development using this algorithm that I often got inaccuracies in the range of 20%, something that is not noticeable when using only the console without printing the times.

github-actions Bot added area: Stepper area: Samples Samples area: Devicetree labels Apr 13, 2025

github-actions Bot requested review from bjarki-andreasen, decsny, dipakgmx, fabiobaltieri, faxe1008, galak, jbehrensnx, kartben, nashif and rruuaanng April 13, 2025 19:26

github-actions Bot assigned kartben Apr 13, 2025

jilaypandya force-pushed the feature/introduce-rudimentary-ramp branch from 3eb28c1 to d4a1f59 Compare April 13, 2025 19:31

jilaypandya mentioned this pull request Apr 13, 2025

Stepper API: Set Ramp Profile #88563

Closed

jilaypandya force-pushed the feature/introduce-rudimentary-ramp branch from d4a1f59 to 161ed77 Compare April 13, 2025 21:26

andre-stefanov reviewed Apr 13, 2025

View reviewed changes

jilaypandya force-pushed the feature/introduce-rudimentary-ramp branch 4 times, most recently from 03d7e6a to 002919a Compare April 14, 2025 07:12

jbehrensnx reviewed Apr 14, 2025

View reviewed changes

kartben assigned jilaypandya and unassigned kartben Apr 14, 2025

rruuaanng reviewed Apr 14, 2025

View reviewed changes

Comment thread dts/bindings/stepper/ramp-parameters.yaml Outdated

decsny removed their request for review April 14, 2025 17:04

jilaypandya force-pushed the feature/introduce-rudimentary-ramp branch from 002919a to 2fb84c6 Compare April 14, 2025 19:33

jilaypandya force-pushed the feature/introduce-rudimentary-ramp branch 2 times, most recently from f0f04fe to e5ab023 Compare April 20, 2025 16:01

dipakgmx reviewed Apr 20, 2025

View reviewed changes

Comment thread drivers/stepper/stepper_common.h Outdated

jilaypandya force-pushed the feature/introduce-rudimentary-ramp branch 2 times, most recently from ca14aeb to bdb0a32 Compare April 21, 2025 09:13

faxe1008 reviewed Apr 22, 2025

View reviewed changes

jilaypandya force-pushed the feature/introduce-rudimentary-ramp branch from bdb0a32 to 1014b4c Compare April 23, 2025 08:08

jilaypandya requested review from andre-stefanov, dipakgmx and faxe1008 April 23, 2025 08:12

jilaypandya force-pushed the feature/introduce-rudimentary-ramp branch 3 times, most recently from 12d8d44 to a4be436 Compare April 23, 2025 17:03

jilaypandya changed the title ~~drivers: stepper: introduce rudimentary ramp control~~ drivers: stepper: introduce rudimentary trapezoidal ramp control Apr 23, 2025

dipakgmx reviewed Apr 24, 2025

View reviewed changes

Comment thread drivers/stepper/gpio_stepper_controller.c Outdated

jilaypandya force-pushed the feature/introduce-rudimentary-ramp branch 2 times, most recently from d263d8e to 314c9e9 Compare April 24, 2025 18:40

faxe1008 reviewed Apr 25, 2025

View reviewed changes

jilaypandya force-pushed the feature/introduce-rudimentary-ramp branch from 314c9e9 to 0be7169 Compare April 25, 2025 14:33

jilaypandya requested review from dipakgmx and faxe1008 April 25, 2025 14:37

jilaypandya force-pushed the feature/introduce-rudimentary-ramp branch from 0be7169 to 402bc78 Compare April 28, 2025 09:00

jbehrensnx reviewed Apr 28, 2025

View reviewed changes

jilaypandya force-pushed the feature/introduce-rudimentary-ramp branch from 402bc78 to 8d25028 Compare April 28, 2025 09:06

jilaypandya and others added 2 commits April 28, 2025 11:15

drivers: stepper: introduce trapezoidal ramp control

6d0b2cf

Introduce rudimentary trapezoidal ramp control using following paper: https://www.boost.org/doc/libs/1_81_0/libs/safe_numerics/example/stepper-motor.pdf Signed-off-by: Jilay Pandya <jilay.pandya@outlook.com>

tests: added unit tests for stepper ramp api

7723317

testing following criteria: - distance profile - first acceleration interval - next step intervals Signed-off-by: Andre Stefanov <mail@andrestefanov.de>

jilaypandya force-pushed the feature/introduce-rudimentary-ramp branch from 8d25028 to 7723317 Compare April 28, 2025 09:19

jilaypandya closed this May 10, 2025

jbehrensnx mentioned this pull request May 12, 2025

Split Stepper Motion Controller <-> Stepper Driver #89786

Closed

	(2 * current_step_interval) / (4 * ramp_position + 1);
	(2 * current_step_interval) / (4 * ramp_position + 3);

Uh oh!

Conversation

jilaypandya commented Apr 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Trapezoidal Ramp Control for Stepper Motors:

Integration in driver

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jilaypandya Apr 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jbehrensnx commented Apr 14, 2025

Uh oh!

Uh oh!

dipakgmx commented Apr 14, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

jilaypandya commented Apr 13, 2025 •

edited

Loading

jilaypandya Apr 13, 2025 •

edited

Loading